Inter-site conferencing is an integral part of many businesses today. Consequently, the capacity for inter-site interaction by exchanging data streams through a shared network such as the public Internet is assuming an increased importance for many companies, both large and small. Many if not most organisations will have systems of some description in place to enable their members to interact not only with other employees operating from different sites, but also with clients and other individuals external to the organisation.
Conventionally, voice conferencing is realised through the use of Voice over Internet Protocol (VoIP) telephony systems, installed and maintained independently by individual organisations and their IT teams. Consequently, where a new or updated version of any of the call control or media handling software currently running on those systems is released, that updated edition can be fully tested against all the types of telephony devices and other hardware in place within the organisation. To minimise disruption, such testing can be done out of hours, or using spare equipment. Testing new software versions in this way can prevent or reduce potential interruptions to users of the conferencing service by allowing any incompatibilities or other teething problems to be resolved prior to commencing live use of the new software.
However, end-users are steadily becoming more demanding in terms of the functionality required of inter-site communications systems, and there is an increasing desire for additional services such as video conferencing. Currently, video telephony also commonly takes place over the public Internet. FIG. 1 shows, schematically, an exemplary prior art network that may be used to implement video IP telephony between physically separate sites.
In the drawing of FIG. 1, a network includes two end-user computing systems, each at a different physical site and each connected to the public Internet 10 by a link 13. In this example, the two sites belong to two independent organisations, the members of which may wish to communicate with one another. However, the telecommunications illustrated may alternatively be between separate sites belonging to one organisation.
The computing system at each site includes a local video server 14, connected to individual video end-systems 12. When a call is initiated from one site to another, a connection is set up between the two servers 14 through the Internet 10, as shown by the dashed line 15.
In the example network of FIG. 1, the software and/or firmware for the devices of the two sites are independent, and communication between the two end-systems is based on standard protocols agreed and published by international standards organisations for interoperability between equipment from different vendors so as to ensure compatibility and smooth communications.
In spite of this, the potential still exists for incompatibilities between the call handling software running at each site. In part, this is due to the complexity and wide feature set of video IP telephony, which are considerably greater than those of VoIP telephony. Associated with that complexity is a correspondingly increased risk of incompatible interactions between equipment, which is typically evident when software is upgraded locally to one individual site. For example, a new version of a video encoder in a sending end-system may implement a new video encoding feature that a receiving end-system may not be equipped to handle. This can cause the receiving system, which may previously have worked reliably, to fail.
In parallel with the growing popularity of video IP telephony within organisations, traditional IP telephony has seen a move in many cases to migrate call control away from individual organisations to multi-tenant, ‘cloud-based’ services that exist to handle call routing to the public switched telephone networks. Since voice services are comparatively simple, this approach can work well in the case of inter-site voice telephony: the risk of unexpected incompatibilities that could arise following a software upgrade somewhere within the multi-tenant cloud infrastructure is comparatively small. Furthermore, the feature set of such services is typically simple (in practice, what is required is often simply the routing of calls between end-users and the public switched telephone network, and between end-users at different sites), so that in the unlikely event of an incompatibility a roll-back to a previous version of the service's software infrastructure is straightforward to implement and often has little or no significant impact on end-user experience.
(The term ‘cloud’ is used throughout this document to refer to any centralised, distributed or shared computing arrangement. Cloud resources are typically geographically separate from end-user systems, are shared by multiple users and are dynamically re-allocated per demand With cloud technology, those multiple users can access a single server (which may be distributed over a number of processing units), to retrieve and update their data.)
The interplay of these two trends—the growing feature set of video telephony and its complexity with respect to more traditional systems; and the outsourcing of voice telephony control—has led to the emergence of state-of-the-art cloud-based outsourced multi-tenanted video telephony services, such as the one shown in overview in FIG. 2, which many organisations are growing to expect.
FIG. 2 shows, schematically, a network implementing a cloud-based video telephony service. Similarly to the network of FIG. 1, two local end-user computing systems are each connected to the Internet 10 by a respective link 13, and include local video end-systems 12. However, differently from the network of FIG. 1 those systems communicate not directly with each other, but via a cloud-based video network 21 on the Internet 10. Each end-system 12 connects to services hosted on the cloud through a router 11 and a cloud-based session border controller (also referred to herein simply as a ‘border controller’) 22, configured to control the signalling between individual sites. End-systems 12 may again make use of an on-site communications server 14 similar to that of FIG. 1, which can simplify the configuration of inter-site connection.
This move towards setups of the kind shown in FIG. 2 introduces new software logistics challenges. As mentioned, video conferencing services often offer feature sets that are far more complex than those of more traditional systems, and can in some cases include still further functionality such as screen sharing and instant messaging. Additionally, the proper handling of video streams over the Internet is complex; the types of video end-systems on offer are diverse and numerous; and multiple organisations having unpredictable and potentially inconsistent configurations may be served by one, same central infrastructure.
These factors all contribute to logistical difficulties in managing software updates within the cloud infrastructure 21, which take on a significant incompatibility risk as compared with legacy environments. In the worst case scenario, an update to the software responsible for the provision of the centralised service may introduce a feature that is demanded by one organisation attached to the outsourced service provider, but is incompatible with one or more mission critical devices of another. In other words, the new feature may be required by one end-user, while another may demand that it is withheld in order for its business to run without interruption.
A second, related problem with which the disclosure is concerned is the logistical challenge presented by the software migration process itself—even when potential incompatibilities are discounted. Traditionally, implementation of a software upgrade to a cloud-based telecommunications service follows one of two general procedures prevailing in the art.
One, presently preferred option is to install the new cloud service software fully on spare physical resources, equivalent to the hardware on which the current version is running, before shutting down the network to enable the configuration database to be updated. Once this is done, service may be resumed.
However, one major drawback of this approach is the investment of resources required: to achieve deployment of every component of the new software version before the switchover commences, all system hardware must be replicated. It will be appreciated that the associated financial cost, as well as the time and the degree of human resources involved, can quickly become prohibitive, in particular in view of the scale of some of the networks existing today.
It is possible to achieve software migration without this investment in duplicate physical resources. However, the only alternative existing today requires the entire video network—including the cloud-based infrastructure itself, as well as all end-systems connected to it—to be shut down for extended periods of time. This gives space for all software components on all systems to be upgraded, and the configuration database updated as appropriate, before service is resumed.
As will be appreciated, however, the required downtime can be extensive and this approach can cause considerable inconvenience to end-users. Furthermore, the interruption of service to all end-users must be synchronised, and the service resumed for each of them only once the migration process is complete across the network. Where the video network is a shared cloud architecture to which hundreds or even thousands of clients are attached, this level of coordination is not always possible and is, at best, extremely challenging.
Thus, there is a need for improved systems and methods for managing updates to the software used to provide cloud-based video telephony services.